Wi-Fi is an example implementation of a Wireless Local Area Network (WLAN) and is based upon the IEEE 802.11 series of protocols. Wi-Fi and other WLAN implementations allow mobile devices equipped with a wireless adaptor to “attach” to wireless Access Points (APs). In order to allow wireless devices to connect to the Internet, APs are in turn connected to Access Routers (ARs) which provide IP routing, Network Address Translation (NAT), and DNS forwarding. In a typical domestic scenario, a WLAN network might consist only of a single wireless AP connected to a single AR. However, within for example a corporate environment, multiple APs may be deployed, connected to one or more ARs. Indeed, a single WLAN network might extend to cover an entire town or city, with many hundreds of wireless APs and multiple ARs. A WLAN 1 network comprising multiple APs 2 and multiple ARs 3 is illustrated schematically in FIG. 1, together with an example wireless terminal 4.
Whilst directed to mobile users, WLANs have traditionally been used to allow Internet access from substantially static users. For example, a user may browse the web using his or her laptop whilst sitting in a railway station or airport terminal. As such, the ability to roam within and between WLAN networks has not been a high priority. This is changing with the introduction of new services such as Voice over IP (VoIP) and multimedia applications (including multimedia calls and IPTV) which are time sensitive and which require a smooth and fast handoff between APs.
Within a WLAN, a Media Access Control (MAC) protocol is used to provide addressing between wireless devices and APs. APs and wireless devices are allocated essentially fixed and unique MAC addresses (within the global MAC address space). The MAC protocol also provides for a Service Set Identifier (SSID) which uniquely identifies a given network. All messages sent between the APs of a WLAN and the attached wireless devices contain (within the MAC headers) a source MAC address, a destination MAC address, and the SSID of the WLAN.
FIG. 2 shows an exchange of signalling associated with a wireless device (or mobile node (MN)) attaching to a WLAN via an AP, assuming that the MN is not currently attached to another AP. According to the 802.11 protocols, the MN sends a probe message on each frequency channel of which it is aware. It must wait a predefined period (or even extended period) between probe messages to receive a probe response from any AP within in range. After all of the channels have been probed, the MN selects that AP from which the strongest signal was received, and sends to that AP (using the AP's MAC address contained within the probe response) an authentication message. The AP carries out a weak authentication on the MN and returns an authentication response.
Following the authentication exchange, the MN sends an association message to the AP. The purpose of this message is to cause the AP to install into its database the MAC address of the MN. When the AP receives a data packet from an upstream AR, the AP uses the database to determine (based upon the destination MAC address of the packet) whether the packet is destined for a MN which it is serving, and therefore whether the AP should broadcast the packet. After updating its database, the AP sends an authentication response message to the MN.
At this point MAC attachment has been completed. It is now necessary for the MN to “attach” at the IP level. This process is initiated by the MN sending to the AP a router solicitation message (RtSol). The AP forwards this message on to the AR which responds with a router advertisement message (RtAdv) containing the IPv6 address prefix to be used by the MN. [Alternatively, if the AR is advertising its prefix via multicast RtAdv messages sent periodically on the link, there is no need for the MN to send a RtSol message.] The MN then determines for itself the Interface Identifier (II) part of the IP address in order to construct a complete address and performs a “uniqueness” test by advertising the address on the local link. The AR maintains a mapping between the MAC address of the MN and the allocation IPv6 address. Subsequently, when the AR receives a packet having the allocated IPv6 address as its destination address, the AR identifies the MAC address of the MN and includes this in a MAC header. The AR also identifies the correct link over which to send the packet (towards the AP), and sends the packet over that link. As described above, the AP uses its own database to determine whether it should broadcast a received packet over the local wireless link.
In order to facilitate the introduction of time sensitive services such as VoIP, it is necessary to enable the handoff of wireless devices at least between APs of a WLAN and preferably also between WLAN networks and WLAN networks and other networks, e.g. 3GPP cellular networks. In the case of an intra-WLAN handover, it is necessary to firstly enable handoff at the MAC layer. IEEE 802.11 specifies the procedure involved. The procedure is illustrated by the signalling flow of FIG. 3 and is broadly similar to that associated with initial attachment to an AP and illustrated in FIG. 2. Typically, when the strength of the signal received from a current AP, referred to hereinafter as the previous AP or pAP, falls below some predefined threshold, the MN repeats the probe exchange in order to identify a new AP (nAP) which is within range. The MN learns from the probe response the MAC address of the nAP, and performs the authentication exchange with the nAP.
The MN then sends a reassociation or rea request to the nAP. This differs from the association message (FIG. 2) in that it contains an identity, i.e. MAC address of the pAP. Upon receipt of the rea, the nAP must first of all confirm with the pAP that it is allowed to accept handoff of the MN, and must then instruct the pAP to remove the MN (MAC address) from its association table. This exchange between the pAP and the nAP requires implementation of an inter AP protocol (IAPP). IAPP protocols are proprietary, and no standardised protocol exists at this time.
Following completion of the MAC handoff (involving as it does the probe delay, authentication delay, and reassociation delay), it is still necessary to perform the IP attach process whereby the MN obtains a new IPv6 address from the nAR. Of course, if the AR to which the nAP is attached turns out to be the same AR to which the pAP is attached, the MN will discover this from the IPv6 address prefix contained in the RtAdv message received from the nAP. In this case, existing sessions can be continued. However, if the AR has changed, existing sessions will be dropped in the absence of a suitable mobility protocol.
By itself, this IP attach procedure provides no mechanism for causing packets directed to a pAR to be tunnelled from that pAR to the nAR. This is important otherwise packets will be dropped until such time as a Correspondent Node has been updated with the MNs new IPv6 address.
Mobile IP is an IETF standard communication protocol designed to allow mobile devices to move within and between access networks whilst maintaining a fixed IP address, thus overcoming the problem identified in the previous paragraph. It relies upon the allocation of a fixed home IP address (HoA) to a user, this address belonging to and identifying the user's home network. When the user roams into a visited network, the visited network allocates a care-of-address (CoA) to the user. This CoA is registered at a Home Agent (HA) within the user's home network, where it is mapped to the HoA. As the user moves, his CoA may change. The HA is updated with the new CoA(s) as the user moves, i.e. by the sending of a Location Update to the HA. A Correspondent Node (CN) will use the HoA as the destination address for the roaming user. Packets are therefore routed from the CN to the user through the home network (unless route optimisation is employed, but this is not considered further here).
In the case of a mobile aware wireless device, a mobile IP layer is introduced into the protocol stack at the device, and is responsible for updating the user's HA with the current CoA. At the application layer, applications are only aware of the HoA. For incoming IP packets, the mobile IP layer substitutes the HoA for the CoA in the destination field before forwarding the packets to the higher layers. For outgoing packets no substitution is required. It has been recognised however that this solution cannot be applied to legacy terminals which do not implement the mobile IP protocol. A solution known as proxy mobile IP has therefore been proposed (also by the IETF) and introduces a new network entity known as the Mobility Access Gateway (MAG), previously referred to as the Proxy Mobile Agent. The MAG handles mobility signalling on behalf of mobile devices and, in particular, is responsible for updating a user's HA with the current CoA. In the case of a WLAN, the MAG is implemented within the AR, as it is the AR which is responsible for allocating (global) IP addresses to wireless devices.
Where a MN has been handed-off from an old to a new AR, one of the new AR's roles (as MAG) is likely to be that of sending a Fast Binding Update message to the old AR. Upon receipt and validation of that message, the old AR will begin tunnelling packets that it receives, addressed to the old CoA, to the new AR. Such packets will be received by the old AR until such time as the MN's HA has been updated with the new CoA.
It will be appreciated that the handoff procedures described above are unlikely to allow users to experience the seamless provision of services to which they have become accustomed, e.g. through use of traditional cellular telephone networks, due in part to the need to complete the MAC layer authentication and association phases before IP mobility procedures can be initiated (and tunnelling of packets between the old and the new ARs can begin). It is desirable to try to introduce further measures to optimise WLAN handoff procedures. The scope for changing the existing 802.11 protocols is much restricted however. For example, it is unlikely that it will be possible to change the message formats (i.e. MAC header) exchanged between the mobile node and the AP, or the highly time consuming probe procedure. Any new solutions must take account of these restrictions.